Overview

Asset Lifecycle Information Management can render vertical menus for relationship templates that are defined an instance’s class and some other object type classes. For example, below is a vertical menu on the left side of the Assets tab for a Document instance:

The concept is that “vertical tabs” represent templates that have been defined for relationship classes that have the current instance’s class (in this case Document class) as a part of the attribute domain definitions on one side (left side) and classes of another object type (in this case Tag Object) on the other side of the attribute domain definition (right side).

A template can be configured that will display in the right pane when a relationship template is selected in the vertical menu. Typically, it is a grid, as in the example above.

The vertical tabs can also be configured to be sub-classes. Usually the first vertical tab one should be the most inclusive- “Show all {{object displayTextLowercase}}”. Narrower relationships should be below it. For the Asset tab in the above Document instance, there could be a vertical tab for only Tunnels or only assets under construction.

Relationships.json

Relationships can be between two classes of different types (examples: Tunnel to Inspection, Tag to Task, Tag to Tag, Organization to Tag) or two classes of the same type (examples: Span to Deck, Tag to Tag, Document to Organization). In some WUIFPlugins there is a relationships.json file which defines how the application will present available relationships. For a key pair of routeId and templateId, there exist relationships that are relevant to when both that route and that template are in use. When applicable subtemplates will be shown in a container (example: a tab’s page).

The relationships.json provides extra information about which relationships and localized words to use, refresh behavior, and which templates to use in the container (details page in the master-detail design pattern ). The empty state template is shown in the container when a query response reports that there are no related instances. A relationship for a relationship tab varies depending upon context, so the route+template pair needs to have the empty state and default template defined.

The container is the details page in the master-detail design pattern.

EC Classes

When a form is created in Bentley Forms Designer, it is displayed on the base EC class to which it is mapped. To create a shared form, create it for a common base class.

The relationships.json configuration file is intended to be used with EC classes, not AssetWise classes. Therefore, when configuring parentClasses and relationshipClasses, be sure to use the EC names from the generated EC schema.

Special Case: Conditions to Tags; Conditions to Tasks

There is a relationship-like "Applies to" property. It works like a foreign key that points to an instance of another type (similar to the "instanceId" of a different objectType).

For example, if a Condition instance needs to be related to a Span instance (a child class of Tag), in AssetWise, the "Applies to" property is defined for the Condition class. "Applies to" is an intrinsic AssetWise property. Similar to Domain Attribute Definitions, it defines to which classes the Condition class can point. "Applies to" is a hierarchy sensitive property. It could be defined to allow Condition to point to Tag polymorphically which would allow Condition instances to point to an instance of any subclass of Tag.

When a relationship exists between a Tag instance and a Task instance, if a new Task is created and points to a Tag instance via "Applies to", AssetWise looks at the parent Tag instance to determine if a relationship exists to an existing Task. For example,

Then AssetWise automatically tries to establish a Parent-Child relationship between the Parent Task and the child Task (assuming it exists, either explicitly or implicitly by way of polymorphism).